Environment and methods for enabling electronic transactions

ABSTRACT

A method includes receiving a request for registered payment options associated with a user computing device, where the request includes an identifier uniquely identifying one of the user computing device and the user. The method includes identifying one or more payment options associated with the device identifier, where each of the one or more payment options is associated with respective payment instrument information. The method includes providing one or more codes, where each code of the one or more codes identifies a respective payment option of the one or more payment options. The method includes receiving a first code of the one or more codes and transaction information. The method includes accessing, based upon the first code, payment instrument information associated with the payment option identified by the first code, and causing the processing of the payment instrument information in relation to a transaction identified by the transaction data.

CROSS REFERENCE TO RELATED APPLICATIONS

This application is a continuation of U.S. patent application Ser. No.15/954,460 filed on Apr. 16, 2018 which issued as U.S. Pat. No.11,100,500 on Aug. 24, 2021 and continuation of U.S. patent applicationSer. No. 13/755,262 filed on Jan. 31, 2013 which issued as U.S. Pat. No.9,947,011 on Apr. 17, 2018, and which claims the benefit of and priorityto U.S. Provisional Patent Application No. 61/728,766 filed on Nov. 20,2012, the contents of which are hereby incorporated by reference intheir entirety for all purposes.

BACKGROUND

Information such as personal data and other sensitive information may bepassed across a network such as the Internet, for example to providecredential information, payment information, or personal accountmanagement information. To protect sensitive information, theinformation can be transmitted over a secure transmission connection,such as Transport Layer Security (TLS) or Secure Socket Layer (SSL).

To secure information from unauthorized review, the information can bedigitally encrypted. One example of digital encryption is public keycryptography. In the public key cryptography scheme, two separate butmathematically-connected keys (e.g., numeric values) are used to securethe information. The first, a public key, is used to encrypt the datausing an encryption algorithm. The second, a private key, can be used bythe receiver of the data to decrypt the encrypted information. Thereceiver supplies the sender with the public key such that the sender iscapable of securely transmitting information to the receiver.

The receiver of sensitive information may be obligated to secure theprivacy of the user from unauthorized access to the sensitiveinformation. Information may be sensitive if the information isconfidential (e.g., industry and/or professional standards indicate thatonly designated parties should have access to the information).Information may be sensitive if a party incurs regulatory obligationsfor handling the information due to exposure to the information.Information may be sensitive if a party incurs potential liability dueto handling of and/or exposure to the information.

An example of sensitive information is payment instrument information,such as a credit card number. When merchants conduct transactions usinga credit card number, a variety of information is requested from thecard holder, such as the credit card number and credit verificationvalue (CVV), name of the card holder as printed on the card, cardexpiration date, and the card holder address. The personal informationentered by the user may be used by a transaction processing system(e.g., credit card processing system) to validate the credit card isbeing used by the credit card holder.

When conducting electronic transactions, payment instrument informationmay be stored for later use. For example, some online retailers providethe user with the opportunity to store information regarding one or morecredit cards for later use. Upon providing user credentials with theretailer (e.g., username and password), the credit card holder may bepresented with the opportunity to select a previously used credit card.When storing information on credit cards for later use, the retailertypically requires the user to provide secure login information (e.g., auser name and password combination). When conducting a latertransaction, the user is prompted for the secure login information priorto being provided the opportunity to use the stored payment instrumentinformation. This often results in the user needing to remember multipleuser names and passwords, as secure login requirements may differ fromretailer to retailer. Additionally, this may result in the userresorting to less secure login information to improve ease ofremembrance.

Alternatively, a user, when conducting electronic transactions, mayregister with an electronic wallet (eWallet) vendor. Through a computerapplication provided by the eWallet vendor, for example, the user mayreceive authorization for conducting a transaction.

There exists a need for a solution that remains resident to theexperience provided by the online retailer, yet bypasses therequirements for remembering retailer-specific usernames and passwordsfor accessing payment instrument information. There additionally existsa need for a solution that allows for the authorizing the transfer ofstored credit card information from a first online retailer to a secondonline retailer, thus providing an enter once solution for accessingpayment instrument information across multiple online retailers.

SUMMARY

In general overview, an intermediary party provides an online retailerwith a software library for building a computing device application(e.g., mobile application) including a software library directed towardsenabling electronic transactions via the intermediary party (e.g.,payment gateway). The software library, for example, may include anumber of function calls directed towards communicating transactioninformation with the intermediary party. The transaction information, insome implementations, is forwarded to the intermediary party from amobile device executing the retailer application via a retailer serverin communication with the retailer application (e.g., servinginformation regarding goods and services for sale to the retailerapplication).

Upon installation and execution of the retailer mobile applicationincluding the software library, a user is provided the opportunity toregister one or more electronic payment instruments, such as creditcards with the intermediary party. Registration, in someimplementations, occurs during an electronic transaction process. Forexample, upon submitting credit card information for remitting paymentduring the transaction process, the user may be prompted with theopportunity to store the credit card information with the intermediaryparty for later use. In some implementations, the retailer mobileapplication provides the user with a credit card entry form that isseparate from the transaction process. For example, the user may beprovided with the opportunity to add, remove, and/or update credit cardinformation without conducting a transaction.

In order for the third party transaction support solution to achieve astrong level of adoption by both merchants and their customers, theprocess for registering payment instruments with the intermediary party,in some implementations, is designed to include as few extra stepsbeyond a typical merchant checkout experience as possible. For example,rather than presenting the customer with registration steps includingcreating a new username, password, and email address to register thecustomer with the intermediary party service, in some implementations,the intermediary party service automates (or semi-automates) theregistration process by saving a portion of the information related tothe payment instrument (e.g., previously entered by the customer via amerchant software application). For example, the automated registrationprocess may be initiated through the customer agreeing to save thepayment instrument information with the intermediary party (e.g., viaselecting an accept control in a user interface generated by a softwarelibrary provided by the intermediary party). In some implementations, touniquely identify the customer, the intermediary party may deriveidentifying information from the customer computing device (e.g., aunique device identifier, telephone number, unique identifier associatedwith the intermediary party software library installed upon the customercomputing device, etc.).

In some implementations, unique identifying information is stored to thecustomer computing device. After registration of a customer with theintermediary party service, in some implementations, the customer can beautomatically identified based upon information derived from and/orstored to the customer computing device. The identification, in someimplementations, is made regardless of whether the customer is accessinga same merchant service (e.g., same merchant software application) or adifferent merchant service (e.g., a software application supplied by asecond merchant registered with the intermediary service). In thismanner, the intermediary party service may automatically look up savedpayment instrument information related to the identified customer. Insome implementations, the intermediary party service prompts thecustomer for authentication information prior to providing informationregarding stored payment instruments. For example, the customer may beprompted, via a user interface, to enter a security code. Upon receiptof the security code, the intermediary party service may validate thesecurity code in relation to the saved payment instrument(s).

Furthermore, for ease of use, the third party transaction supportsolution, in some implementations, includes migration of registeredpayment instruments between member merchants. After registration of apayment instrument with the third party payment gateway, in someimplementations, payment instrument information may change (e.g.,updated expiration date, etc.). Upon addition or change of credit cardinformation, in some implementations, the information is shared (e.g.,upon user authorization) with the intermediary party.

In some implementations, if the user elects to use the intermediaryparty's service, the intermediary party can save the user's credit cardinformation and present the user the option to easily share that creditcard information with other retailers. For example, the user may installa second retailer application associated with a second online retailer.Upon conducting a transaction, if the second retailer application isregistered with the intermediary party, the intermediary party maypresent, via the second retailer application, the credit card stored bythe user in relation to the first retailer application. In someimplementations, the intermediary party associates the credit cardinformation with the second retailer application using an identifierderived from the mobile device. If the user wishes to use the storedcredit card information to perform a transaction with the secondretailer, the user can authorize the intermediary party to share thestored credit card information via the software library embedded withinthe second retailer application so that the user does not have tomanually enter all of the credit card information directly into a creditcard entry form supplied by the second retailer.

In some implementations, upon subsequent transactions, the retailerapplication, with support from the intermediary party, presents thepreviously stored credit card for use in the transaction. Upon selectionby the user, in some implementations, the transaction proceeds withpayment processing. For example, the retailer application may supportone-touch transaction processing upon a mobile device without promptingthe user for further entry of information, such as a passwordinformation. In other implementations, the user is first prompted toauthenticate the card with authentication information. To authenticatethat the credit card holder is conducting the transaction via the mobiledevice executing the retailer application, in some implementations, thesoftware library of the retailer application requests authenticationinformation that can be used to authenticate the credit card with thecredit card processor. For example, the software library may request aCVV code or zip code to authenticate use of the credit card. Thesoftware library portion of the retailer application may send theauthentication information to the intermediary party, where theintermediary party may communicate the authentication information andstored credit card information to a processing server for validation ofthe information.

Applications for the systems and methods described herein are notlimited to the aforementioned examples, but may be deployed in anynumber of contexts, as would be understood by one of ordinary skill inthe art. Contents of the background are not to be considered as anadmission of the contents as prior art.

In one aspect, the present disclosure describes a method includingreceiving, via a network, a request for registered payment optionsassociated with a user computing device, where the request includes anidentifier, where the identifier uniquely identifies one of the usercomputing device and the user. The method may include identifying, by aprocessor of a second computing device, one or more payment optionsassociated with the device identifier, where each of the one or morepayment options is associated with respective payment instrumentinformation. The method may include providing, via the network,responsive to the request, one or more codes, where each code of the oneor more codes identifies a respective payment option of the one or morepayment options. The method may include receiving, via the network,responsive to providing the one or more codes, a first code of the oneor more codes and transaction information, and accessing, by theprocessor, based upon the first code, payment instrument informationassociated with the payment option identified by the first code. Themethod may include causing, by the processor, the processing of thepayment instrument information in relation to a transaction identifiedby the transaction data.

In some embodiments, causing the processing of the payment instrumentinformation may include providing the payment instrument information toa credit card processing server. The method may include receiving, fromthe credit card processing server, a processing result associated withthe payment instrument information.

In some embodiments, receiving the first code may include receiving anauthentication value associated with the first code. The method mayinclude authenticating, based in part upon the authentication value, useof the payment instrument information. The authentication value mayinclude one of a CVV code and a zip code. Causing the processing of thepayment instrument information may include causing the processing of thepayment information and the authentication value to validate theauthentication value in relation to the payment information. The methodmay further include receiving, responsive to causing the processing ofthe payment information, an indication of validation of the paymentinstrument information.

In some embodiments, the method includes, after receiving the first codeand the transaction information, providing, to the user computingdevice, a temporary token associated with the payment instrument. Themethod may further include receiving, via the network, from an entitycomputing device, the temporary token, and providing, to the entitycomputing device, responsive to receiving the temporary token, a paymentinstrument token associated with the payment instrument information.

In some embodiments, the request for registered payment options isforwarded by an entity computing device from the user computing device.Providing the one or more codes may include providing the one or morecodes to the entity computing device for provision to the user computingdevice. The request for registered payment options may originate from anentity application executing upon the user computing device, where theentity application includes a software library configured forcommunicating information with the second computing device.

In some embodiments, the request further includes a retail identifieridentifying a retail entity. Identifying the one or more payment optionsmay include identifying that none of the one or more payment options isassociated with the retail entity identifier. The method may furtherinclude, prior to providing the one or more codes, requestingauthorization to associate the one or more payment options with theretail entity identifier, and receiving authorization to associate theone or more payment options with the retail entity identifier.

In one aspect, the present disclosure describes a system including aprocessor and a memory, the memory storing instructions that, whenexecuted by the processor, cause the processor to receive, via anetwork, from an entity computing device, a request for registeredpayment options associated with a user computing device, where therequest includes an identifier, where the identifier uniquely identifiesone of the user computing device and the user. The instructions maycause the processor to, responsive to the request, provide, via thenetwork, to the entity computing device, an indication that no paymentoptions are associated with the identifier. The instructions may causethe processor to, receive, via the network, payment instrument dataassociated with the user, and associate, with the identifier, thepayment instrument data and a unique token for identifying the paymentinstrument data. The instructions may cause the processor to, provide,to the entity computing device, the unique token. The instructions maycause the processor to, cause the payment instrument data to be storedfor future use.

In some embodiments, receiving the payment instrument data includesreceiving the payment instrument data encrypted using an encryptiontechnique capable of being decrypted by the system, where the entitycomputing device is disallowed unencrypted access to the paymentinstrument data.

In some embodiments, the instructions, when executed, further cause theprocessor to cause the processing of the payment instrument information.The payment instrument data may be processed by a third party paymentinstrument processing system to authenticate the payment instrumentinformation. The instructions, when executed, may further cause theprocessor to receive, from the third party payment instrument processingsystem, a processing result. Receiving payment instrument data mayfurther include receiving transaction data. The payment instrument datamay be processed by a third party payment instrument processing systemto conduct a transaction related to the transaction data.

In one aspect the present disclosure describes a non-transitory computerreadable medium having instructions stored thereon, where theinstructions, when executed by a processor, cause the processor toretrieve, from a designated storage area of a computing device, a deviceidentifier. The instructions may cause the processor to provide, via anetwork to a third party computing system, the device identifier, and,responsive to providing the device identifier, receive, from the thirdparty computing system, information regarding one or more paymentoptions, where the one or more payment options are associated with thedevice identifier, and the one or more payment options consist ofnon-sensitive information. The instructions may cause the processor toprepare, for presentation to a user of the computing device within anentity application, a graphical user interface presenting the one ormore payment options for selection. The instructions may cause theprocessor to, receive, responsive to presentation of the one or morepayment options, an indication of selection of a first payment option ofthe one or more payment options. The instructions may cause theprocessor to provide, via the network, for processing payment with thethird party computing system, the first payment option and transactiondata associated with a transaction related to the first payment option,where the graphical user interface is presented within an applicationassociated with an entity, where the entity is disallowed access to thedevice identifier.

In some embodiments, the instructions further cause the processor toprepare, for presentation to the user within the entity application, asecond graphical user interface presenting a request for authenticationinformation associated with the first payment option, where providingthe first payment option and transaction data further includes providingan authentication value entered by the user via the second graphicaluser interface. The authentication value may include payment instrumentinformation associated with the first payment option. The authenticationvalue may include one of a CVV code and a zip code. The user device mayinclude the computer readable medium. The device identifier may includea unique identifier generated by the third party computing system.

BRIEF DESCRIPTION OF THE DRAWINGS

The foregoing and other objects, aspects, features, and advantages ofthe disclosure will become more apparent and better understood byreferring to the following description taken in conjunction with theaccompanying drawings, in which:

FIG. 1 is a block diagram of an example system for enabling electronictransactions via a mobile computing device;

FIG. 2 is a flow chart of an example method for registering and usingcredit cards in electronic transactions;

FIGS. 3A through 3C illustrate a series of example user interfaces forconducting a transaction with a registered credit card;

FIGS. 4A through 4C illustrate a series of example user interfaces forregistering a credit card for use in future transactions;

FIG. 5A is a swim lane diagram of an example method for registering acredit card for use in future transactions;

FIG. 5B is a swim lane diagram of an example method for conducting atransaction with a registered credit card;

FIG. 6 is a block diagram of a network environment for enablingelectronic transactions on a mobile device; and

FIG. 7 is a block diagram of a computing device and a mobile computingdevice.

The features and advantages of the present invention will become moreapparent from the detailed description set forth below when taken inconjunction with the drawings, in which like reference charactersidentify corresponding elements throughout. In the drawings, likereference numbers generally indicate identical, functionally similar,and/or structurally similar elements.

DETAILED DESCRIPTION

FIG. 1 is a block diagram of an example system 100 for enablingelectronic transactions on a mobile device 102. The mobile device 102,in some examples, may be a smart phone, personal digital assistant(PDA), tablet computer, or other personal electronic device capable ofthe installation and execution of a software application designed toenable a user to purchase goods and/or services from a retailer throughelectronic transactions. Rather than a mobile device, in someimplementations, the device 102 may be a desktop computer, laptopcomputer, Smart TV, Internet appliance, or other computing devicecapable of the installation and execution of a software applicationdesigned to enable a user to purchase goods and/or services from aretailer through electronic transactions. While conducting an electronictransaction, the mobile device 102 relays transaction information,through a retail mobile application 108, to a payment gateway 104. Thepayment gateway 104 manages and validates stored payment instrumentinformation on behalf of the retailer. During an electronic transactionconducted via the retail mobile application 108, the payment gateway 104enables transaction processing through a payment instrument processingservice 106.

The retail mobile application 108 installed upon the mobile device 102,in some implementations, is configured to communicate transactioninformation to the payment gateway 104 using a payment software libraryportion 110 of the retail mobile application 108. The payment softwarelibrary portion 110 of the retail mobile application 108, in someimplementations, is provided by the payment gateway 104 (e.g., a thirdparty transaction processing solution provider) to the retailer forincorporation into the retail mobile application 108. The paymentssoftware library portion 110 executes function calls made by the retailmobile application 108 to communicate the transaction information to thepayment gateway 104. The payment software library 110, for example, isprovided to the retailer by the payment gateway 104 to incorporate intothe retail mobile application 108 during development. The paymentsoftware library 110 includes function calls supporting the collectionand repeated use of payment instrument information.

A user may install the retail mobile application 108 upon the mobiledevice 102 and initiate a transaction. The payment software library 110,in some implementations, provides a unique device identifier 128 to thepayment gateway 104 to identify any payment instruments alreadyregistered to the payment gateway 104 by the mobile device 102. Forexample, the unique device identifier may include the telephone numberof the mobile device 102, a unique device identifier configured by themanufacturer of the mobile device 102, or a unique identifier allocatedby the retailer via the retail mobile application 108.

In other implementations, if a device identifier 128 has not yet beenestablished, the payment software library 110 requests a uniqueidentifier for the mobile device 102. For example, the payment gateway104 may allocate a unique identifier (e.g., random number, string, etc.)for uniquely identifying the mobile device 102. The retail mobileapplication 108 may store the unique identifier in a memory locationaccessed by the payment software library 110 (e.g., a memory locationavailable to any mobile application executing the functionality providedby the payment software library 110). The payment gateway 104, uponreceipt of the device identifier 128, attempts to identify one or morestored (e.g., registered) cards using a card identification engine 116.For example, the card identification engine 116 may match the deviceidentifier 128 to device identifiers 124 stored within a payment gatewaydatabase 122. Each device identifier 124 within the payment gatewaydatabase 122, for example, may be associated with one or more cardidentifiers 126. Although described in the following examples asoperations performed in relation to a credit card, the card identifiers126, in some examples, may include identifiers representing creditcards, debit cards, stored value cards, gift cards, and other electronicpayment instruments.

If no cards are identified, a routine may be initiated by the retailmobile application 108 and a card storing engine 114 to collect andstore information for a new payment instrument. The payment softwarelibrary 110, in some implementations, includes one or more subprogramsto encrypt and transmit payment instrument information to the paymentgateway 104 for secure storage. The payment gateway 104, in someimplementations, enables encryption of the information upon the mobiledevice 102 through an encryption key allocated to the retailer. Theencryption mechanism, for example, may be described in U.S. patentapplication Ser. No. 13/633,106, entitled “Differential Client-SideEncryption of Information Originating from a Client”, and filed Oct. 1,2012, the contents of which are hereby incorporated by reference in itsentirety.

If, instead, one or more cards were previously registered by the mobiledevice 102 (e.g., through the retail mobile application 108 or anotherapplication configured to use the payment software library 110 tocommunicate with the payment gateway 104), the card identificationengine 116 may return registered cards 130 to the retail mobileapplication 108. The information provided by the payment gateway 104regarding each of the registered cards 130, for example, may include aunique card identifier, a payment instrument type (e.g., AmericanExpress, Mastercard, Visa, etc.), the last four digits of the accountnumber, and/or the expiration date of the card.

The retail mobile application 108 may present the registered cards 130to the user for selection. The registered cards 130, for example, mayeach be identified to the user using a portion of the information (e.g.,payment instrument type, last four digits of the account number, and/orthe expiration date of the card).

Upon selection of one of the registered cards 130, in someimplementations, the user is presented with a request for authenticationinformation 132 to authenticate the user as the cardholder. Theauthentication information 132, in some implementations, includes avalue that can be used by the payment instrument processing service 106to validate card information. In some examples, the authenticationinformation 132 may include a CVV code and/or a zip code of the cardholder. In other implementations, payment processing proceeds without anauthentication requirement. For example, based upon one or more ofretailer preferences, user preferences, and type of mobile device 102(e.g., personal device such as a smart phone vs. multi-user (e.g.,family, etc.) device such as a tablet computer), the retail mobileapplication 102 may identify whether to proceed with payment or to firstauthenticate a selected payment instrument. In some implementations, theretail mobile application 108 is hardcoded to always authenticate.

Upon receipt of the authentication information 132, in someimplementations, a card validation engine 118 of the payment gateway 104provides the authentication information 132 to the payment instrumentprocessing service 106 along with credit card information 134. Thepayment processing service 106 conducts a standard verificationprocedure (e.g., verifying matching information between the cardinformation 134 and the authentication information 132) and provides anauthorization result 136 to the payment gateway 104 in response. Thecard validation engine 118 then provides the authorization result 136 tothe payment software library 110 of the retail mobile application 108.

In some implementations, a user password may be used in addition to orin lieu of the credit card-based authentication information 132. Forexample, for additional security, a user may password protect the retailmobile application 108 to avoid having purchases made without theconsent of the cardholder. In another example, if the card holder hasdifficulty remembering the CVV number, the cardholder may insteadpassword protect the card authorization process provided by the paymentsoftware library 110. The payment gateway 104, for example, mayauthenticate password information provided by the user.

Having authorized the credit card for use with the transaction, theretailer may rely upon the payment gateway 104, upon receipt oftransaction data (e.g., amount, payee, etc.) to conduct the transaction,for example using a payment processing engine 120. Examples of thefunctionality of the processing of the transaction are described infurther detail in U.S. patent application Ser. No. 13/633,106, entitled“Differential Client-Side Encryption of Information Originating from aClient”, and filed Oct. 1, 2012.

Should the user install a second mobile application configured toconduct transactions via the payment gateway 104 (not illustrated), insome implementations, the second mobile application may use the paymentsoftware library 110 to display a list of the credit cards 130 that theuser previously saved in response to the second mobile applicationproviding the device identifier 128 to the payment gateway 104. In thismanner, once a user has registered one or more payment instruments withthe payment gateway 104 via the mobile device 102, all applicationsconfigured to conduct transactions via the payment gateway 104 (e.g.,all applications performing functionality supported by the paymentsoftware library 110) may present that user the opportunity to use thosepayment instruments which were previously registered via other retailermobile applications. Upon entering the credit card transaction form ofthe second retailer mobile application, for example, the user may bepresented with the opportunity to authorize the second retailer mobileapplication to receive the payment instrument information (e.g., creditcard number, expiration date, etc.) stored in relation to the retailermobile application 108. For example, the user may complete authorizationof payment instrument sharing between the retailer mobile application108 and the second application by completing an authorization steppresented by the payment software library 110. Authorization, forexample, may include entering credit card authentication information(e.g., the CVV) for each saved payment instrument being authorized. Thisand other features are described in greater detail below.

FIG. 2 is a flow chart of an example method 200 for registering andusing credit cards in electronic transactions. The method 200 may beperformed, for example, by the retail mobile application 108 incooperation with the software payment library 110 executing upon themobile device 102.

In some implementations, the method 200 begins with entering a paymentdialogue (202) of a retail mobile application configured to enableelectronic transactions via a payment gateway. The payment dialogue, forexample, may include purchase information (e.g., a list of itemsselected for purchase, a total funds owed, payment instrumentinformation, etc.). The user may enter the payment dialogue, in someexamples, from within a shopping cart review or upon selecting a controlto make a purchase.

In some implementations, if no payment instruments have been registeredwith the mobile device (204), a new payment instrument entry dialoguemay be entered (206). The new payment instrument entry dialogue includesa request for payment instrument information. For example, one or moreinput fields may be presented to the user for entering paymentinstrument information.

If the new payment instrument is to be stored for future use (210), insome implementations, registration of the new payment instrument isrequested (212). In some implementations, upon entry, by the user, ofpayment instrument information the user is presented with the option tostore the new payment instrument information with a third party entity,such as the payment gateway 104 described in relation to FIG. 1. Theoption may be presented by a routine provided by the payment softwarelibrary 110. In other implementations, the payment instrumentinformation may be automatically stored (e.g., by default, based uponpreviously configured user preferences, etc.). In some implementations,the payment instrument information may include authenticationinformation, such as, in some examples, a CVV code, expiration date, oruser password, authenticating the payment instrument and/or the usersupplying the payment instrument information. The request, for example,may be relayed to the payment gateway 104.

In some implementations, validation of the registration of the newpayment instrument is received (214). For example, the payment gateway104 may provide the software payment library 110 of the retail mobileapplication 108 with a validation of the registration of the new paymentinstrument.

If, rather than entering new payment instrument information, one or morepayment instruments were found to be previously registered with themobile device (204), in some implementations, the one or more registeredpayment instruments are presented as payment options to the user (216).For example, the a routine provided by the software payment library 110of the retail mobile application 108 may present each registered paymentinstrument through partial card identification (e.g., credit card type,payment instrument name, expiration date, last four digits of theaccount number, etc.). A selectable control may be included in thepresentation of each payment instrument configured, upon selection, toinitiate payment processing using the associated payment instrument.

In some implementations, a payment instrument selection andcorresponding authentication value is received (218). In someimplementations, the authentication value relates to the paymentinstrument. For example, the payment instrument may be a credit card,and the authentication value may include the CVV code and/or user zipcode for authentication with a credit card processing system, such asthe payment instrument processing service 106 described in relation toFIG. 1. In some implementations, the authentication value relates to ageneral authentication. For example, the user may password protect theretailer mobile application from unauthorized credit card use. Inanother example, the user may biometrically protect (e.g., fingerprintscan, voice scan, etc.) the retailer mobile application fromunauthorized credit card use. In other implementations, noauthentication value is required. For example, if the method 200 isbeing performed on a single user device, the user may not be required toauthenticate the selection of the payment instrument. Authentication, insome implementations, may be optional based on one or more of retailerpreference settings and user preference settings.

In some implementations, validation of the payment instrument isrequested (220). If the authentication value relates to the paymentinstrument, in some implementations, the payment gateway may forward theauthentication information and credit card information (e.g., as storedwith the payment gateway) to the payment instrument processing service106 (as described in relation to FIG. 1) for validation. If, instead,the authentication value relates to personal authentication (e.g.,password, biometric detail, etc.), in some implementations, the personalauthentication value is provided to the payment gateway 104 forauthentication. In other implementations, rather than requestingvalidation, validation may be performed within the mobile device. Forexample, the retail mobile application may validate the biometricinformation using functionality available within the mobile device 102.

If authentication of the payment instrument has failed (222), in someimplementations, the user may be prompted for re-entry of theauthentication value (224) and validation of the authenticationinformation may be requested again (220). In some implementations, theuser may be provided with a certain number of attempts (e.g., 3, 5,etc.) to present valid authentication information prior to being deniedaccess to the payment instrument for completing the transaction.

If, instead, the payment instrument is authenticated (222), in someimplementations, the transaction is initiated via the selected paymentinstrument (226). For example, the transaction may be initiated via thepayment gateway 104. Processing of the transaction, in someimplementations, may be conducted external to the viewpoint of the userinterface of the retail mobile application 108. For example, the usermay be redirected to continue interacting with the retail mobileapplication 108 while the transaction is processed in the background.

In some implementations, confirmation information is presented to theuser (228). The confirmation information, in some implementations,relates to success in initiating transaction processing via the paymentgateway 104. For example, the actual transaction may be pendingprocessing via the payment instrument processing service 106. In otherimplementations, the confirmation information relates to successfulcompletion of payment of the transaction. The confirmation information,in some implementations, is presented to the user outside the retailermobile application 102. For example, a retailer server may email theuser regarding the details of the completed transaction.

While described in a particular series of steps, in someimplementations, one or more steps of the method 200 may be conducted ina different order or in parallel with each other. For example,transaction may be initiated using the new payment instrument (226)prior to storing the new payment instrument (210). In someimplementations, one or more steps may be combined or split into two ormore steps. For example, rather than receiving selection of the paymentinstrument and an authentication value (218), in some implementations,an authentication value (e.g., password, biometric identifier, etc.) maybe obtained prior to presenting the payment instrument options to theuser (216). In some implementations, one or more steps may be added oradjusted within the method 200. For example, in some implementations,rather than requesting a new payment instrument (206), the method 200may present one or more stored payment instruments affiliated with theretailer. In one example, the retailer may store payment instrument dataon a retailer server. Further to this example, the retailer, uponauthorization from the user, may forward payment instrument data to thepayment gateway for entry as a new payment option. In another example,the retailer may use a third party service for storage of paymentinstrument data, such as the payment gateway 104 described in relationto FIG. 1. If the payment gateway 104 has stored retailer-specificpayment instruments related to the user in the past, for example, theuser may be prompted to migrate the previously stored payment instrumentfor usage as a payment instrument registered to the particular device(e.g., a payment instrument available for use to any applicationexecuting upon that mobile device that is configured to use the paymentinstrument gateway). Other modifications of the method 200 are possiblewithout exceeding the scope and purpose of the method 200.

FIGS. 3A through 3C illustrate a series of example user interfaces forconducting a transaction with a registered credit card. The userinterfaces, for example, may be presented within the retailer mobileapplication 108 by the payment software library 110, as described inrelation to FIG. 1.

As illustrated in FIG. 3A, an example payment dialogue screen 300includes a stored payment instrument option 302. A user may select thestored payment instrument option 302 and select a submit payment control304 to initiate processing of a transaction payment using a paymentinstrument registered with a payment gateway, such as the paymentgateway 104 described in relation to FIG. 1.

As illustrated in FIG. 3B, an example information dialogue screen 320 ispresented to the user, for example upon selection of a “how it works”control 306 with the stored payment instrument option 302. Within theinformation dialogue screen 320, an information box 322 is presented tothe user, explaining the stored payment instrument option 302.

As illustrated in FIG. 3C, an example payment instrument validationdialogue screen 340 is presented to the user, for example upon selectionof the stored payment instrument option 302. Within the paymentinstrument validation dialogue screen 340, a text entry control 342provides the user with the opportunity to present payment instrumentauthentication information (e.g., the credit card CVV). Upon completionof entering the authentication information into the text entry control342, the user, in some implementations, selects a submit control 344 tosubmit the authentication information for validation.

FIGS. 4A through 4C illustrate a series of example user interfaces forregistering a credit card for use in future transactions. The userinterfaces, for example, may be presented within the retailer mobileapplication 108 by the payment software library 110, as described inrelation to FIG. 1.

As illustrated in FIG. 4A, an example payment dialogue screen 400presents the user with a series of information entry controls 402 toenter payment instrument information (e.g., credit card information,personal information, etc.). A user may complete the requestedinformation in the information entry controls 402 and select a submitpayment control 404 to initiate processing of a transaction paymentusing the entered payment instrument information. In someimplementations, the user may select a save option 404 to save the newpayment instrument with a payment gateway, such as the payment gateway104 described in relation to FIG. 1. Upon entering the paymentinstrument information and, optionally, selecting the save option 404,the user may select a submit payment control 406 to initiate processingof a transaction payment using the entered payment instrument.

In some implementations, upon selection of a how it works control 408,the user is presented with an information dialogue 422, as illustratedin relation to a screen shot 420 of FIG. 4B. Turning to FIG. 4B, theinformation dialogue 422 explains the storage of the payment instrumentinformation with the payment gateway.

Further details regarding the functionality of storing the paymentinstrument with the payment gateway, in some implementations, arepresented to the user upon selection of a more control 424. For example,turning to FIG. 4C, a screen shot 440 illustrates an informationdialogue 442 discussing the functionality of storing the paymentinstrument with the payment gateway.

FIGS. 5A and 5B illustrate swim lane diagrams of example methods forregistering, accessing, and using payment instrument information storedwith a third party entity (e.g., payment processing gateway) forconducting electronic transactions with another entity (e.g., retailer).The methods involve an entity application 502 executing upon a computingdevice (e.g., personal electronics device, home computer, mobile device,etc.). The entity application 502, for example, may be the retail mobileapplication 108 executing upon the mobile device 102, as described inrelation to FIG. 1. The entity, for example, may include a retailer orother organization providing goods and/or services for purchase via theentity application 502. The entity application includes third partysoftware algorithms, for example in the form of the software paymentlibrary 110 as described in relation to FIG. 1, to enable the processingof transactions. In some implementations, the third party softwarealgorithms provided within the entity application allow paymentinstrument information and transaction processing to proceed withoutexposing sensitive information (e.g., credit card number, etc.) to theentity. The third party software algorithms of the entity application502 communicate information to a payment gateway 506. In someimplementations, the third party software algorithms of the entityapplication 502 relays information to the payment gateway 506 (e.g., thepayment gateway 104 as described in relation to FIG. 1) via an entityserver 504. For example, non-sensitive information may be exposed to theentity server 504 such that the entity may track transaction processingevents without exposure to the sensitive information. In otherimplementations, the third party software algorithms of the entityapplication 502 issues separate messages to the entity server 504 (e.g.,lacking sensitive information and other payment gateway specificinformation) and the payment gateway 506. The payment gateway 506, intum, presents information to a payment instrument processing server 508(e.g., the payment instrument processing service 106 as described inrelation to FIG. 1) for processing of a payment instrument involved in atransaction. In this manner, the payment gateway 506 shields the entityserver 504 from direct handling of sensitive (e.g., paymentinstrument-related) information by handling the transactioncommunications on behalf of the entity. Additionally, the paymentgateway 506 manages payment instrument options for the computing deviceexecuting the entity application 502, such that other applicationsexecuting upon the computing device may take advantage of paymentinstruments previously registered via the payment gateway 506. Forexample, other applications containing the third party softwarealgorithms may share in information previously stored with the paymentgateway 506 via the entity application 502.

Turning to FIG. 5A, an example method 500 for registering a credit cardwith a third party entity, via an application provided by anotherentity, for use in future transactions is presented. The method 500, insome implementations, begins with an entity application 502 requestingpayment options (510 a) from the entity server 504. In someimplementations, the payment software library of the entity application502 issues the request 510 a. The request, for example, may includeinformation identifying the computing device executing the entityapplication 502. In some implementations, the entity server 504 forwardsthe request for payment options (510 b) to the payment gateway 506. Inother implementations, the payment software library of the entityapplication 502 requests payment options directly from the paymentgateway 506.

In some implementations, the payment gateway 506 attempts to identifythe computing device (512). If the computing device is not identified,or if there are no active (e.g., not expired) payment instrumentsregistered in relation to the computing device, the payment gateway 506responds (514 a) to the entity server 504 informing the entity server504 that no payment options are registered. The entity server 504, intum, informs the entity application 502 that no payment options areregistered (514 b). In other implementations, the payment gateway 506responds directly to the payment software library portion of the entityapplication 502. In some implementations, along with being informed ofthe lack of registered payment options, the entity application 502 isprovided a session identifier for a transaction session established withthe payment gateway 506.

In some implementations, the entity application 502 presents a paymentinstrument entry dialogue (516) to the user of the computing device,such as the screen shot 400 illustrated in FIG. 4A. For example, theentity application 502 may present a credit card form for enteringcredit card information. In some implementations, the payment instrumententry dialogue is presented by the payment software library portion ofthe entity application 502.

In some implementations, the entity application 502 presents an option(518) for the user to store a new payment instrument with the paymentgateway 506. For example, the payment software library portion of theentity application may present an offer to store payment instrumentinformation with the payment gateway 506. In some implementations, theoption may be presented in the same user interface as the paymentinstrument entry dialogue, for example as illustrated in FIG. 4A. Inother implementations, the option may be presented as a follow-on query,for example upon input, by the user, of new payment instrumentinformation.

In some implementations, encrypted payment instrument data and a sessionidentifier are transmitted (520 a) from the entity application 502 tothe entity server 504. The payment software library portion of theentity application 502, for example, may provide the encrypted paymentinstrument data. The entity server 504, in turn, forwards the encryptedpayment instrument data and session identifier (520 b) to the paymentgateway 506. The entity server 504, in some implementations, logsinformation related to the payment instrument data, such asnon-encrypted (e.g., public) information. In other implementations, theentity application 502 transmits the encrypted payment instrumentinformation and the session identifier directly to the payment gateway506.

The payment gateway 506, in some implementations, forwards paymentinstrument data for processing (522) with the payment instrumentprocessing server 508. For example, the payment gateway 506 may decryptthe payment instrument data previously encrypted by the payment softwarelibrary portion of the entity application 502. The payment softwarelibrary portion of the entity application 502, for example, may encryptthe payment instrument data using an encryption algorithm provided bythe payment gateway 506.

In some implementations, the payment instrument processing server 508processes the payment instrument data (524). The payment instrumentprocessing server 508 then provides a result related to the processingof the payment instrument data (526) to the payment gateway 506. Theresult, for example, may include verification of the user'sauthorization to use the payment instrument for the transaction. Inanother example, the result may include verification of success ofpayment using the payment instrument.

The payment gateway 506, in some implementations, generates a uniquetoken associated with the payment instrument (528). The unique token,for example, may be used by the entity application 502 to identify thepayment instrument when conducting a transaction at a later time. Theentity server 504, for example, may recognize the unique token andassociate a transaction with a particular payment instrument withoutdirectly having access to the payment instrument information. In someimplementations, the unique token is generated prior to completion ofprocessing of the payment instrument data For example, upon validationof credit card information but prior to completion of a payment usingthe credit card, the payment gateway 506 may generate a unique tokenassociated with the credit card.

In some implementations, the payment gateway 506 provides the uniquetoken and the processing result (530) to the entity server 504. Theentity server 504, in some implementations, forwards at least one of theprocessing result and the unique token (532) to the entity application502. If the result relates to the processing of a payment, theprocessing may occur at some time after the submission of paymentinformation by the user. In this circumstance, the result may bepresented to the user via a different communication method, such as anemail alert. In some implementations, the token may be reserved by theentity server 504 and withheld from the entity application 502, forexample for security purposes.

Turning to FIG. 5B, an example method 550 for conducting a transactionwith a registered credit card, in some implementations, begins with theentity application 502 requesting payment options (552 a) from theentity server 504. The request may be provided by a payment softwarelibrary portion of the entity application 502. The request, for example,may include information identifying the computing device executing theentity application 502. In some implementations, the entity server 504forwards the request for payment options (552 b) to the payment gateway506. In other implementations, the entity application 502 communicatesdirectly with the payment gateway 506.

In some implementations, the payment gateway 506 attempts to identifypayment instruments registered with the computing device (554). Thepayment gateway, in some implementations, provides codes associated withone or more registered payment options (556 a) to the entity server 504.In some implementations, the codes are each unique tokens previouslygenerated by the payment gateway 506 to identify the registered paymentoptions. In some implementations, the codes include information used touniquely identify information (e.g., stored tokens, stored publicinformation) related to the payment options. The unique identificationinformation, for example, may bet stored by the entity server 504 or bythe computing device executing the entity application 502.

In some implementations, the entity server 504 forwards the codes forthe one or more registered payment options (556 b) to the entityapplication 502. For example, the entity server 504 may supply the codesfor the one or more registered payment options to a payment softwarelibrary portion of the entity application 502. Additionally oralternatively, the entity server 504 may supply paymentinstrument-related information identified as being associated with thecodes. In other implementations, the payment gateway 506 may supplycodes directly to the payment software library portion of the entityapplication 502, and the payment software library portion of the entityapplication 502 may correlate the codes with stored public informationrelated to each payment instrument (e.g., as stored on the mobile deviceexecuting the entity application 502).

In some implementations, the payment software library portion of theentity application 502 presents a payment option selection dialogue(558). The payment option selection dialogue, for example, may includecontrols associated with each of the payment options identified by thepayment gateway 506, such as the control illustrated in relation to FIG.3A.

In some implementations, the entity application 502 transmits (560) thecode associated with the selected payment method and an authenticationvalue to the payment gateway 506. The payment software library portionof the entity application 502, for example, may transmit the informationto the payment gateway 506. The authentication value, for example, mayinclude a CVV code, user zip code, or other information useful to thepayment instrument processing server 508 in validating the user accessto the payment instrument.

In some implementations, the payment gateway 506 identifies paymentinstrument data associated with the code (562). For example, sensitiveinformation, such as a credit card number, stored by the payment gateway506 may be retrieve in response to receipt of the code provided by thepayment software library portion of the entity application 502.

In some implementations, the payment gateway 506 forwards paymentinstrument data and the authentication value for validation (564) withthe payment instrument processing server 508. In some implementations,the payment instrument processing server 508 processes the paymentinstrument data (566). In some implementations, the payment processingserver 508 provides validation of the payment instrument data (568) tothe payment gateway 506.

In some implementations, the payment gateway 506 generates a temporarytoken associated with the payment instrument (570). Rather thanproviding the actual unique token (e.g., generated in step 528 of method500), for example, the payment gateway 506 may secure the paymentinstrument information by transmitting a temporary token to the entityapplication 502. In some implementations, the payment gateway 506transmits the temporary token (572) to the entity application 502. Forexample, the temporary token may be provided to the payment softwarelibrary portion of the entity application 502.

In some implementations, the entity application 502 transmits thetemporary token (574 a) to the entity server 504. For example, thesoftware library portion of the entity application 502 may provide thetemporary token to the entity server 504. The entity server 504, in someimplementations, forwards the temporary token (574 b) to the paymentgateway 506. Responsive to receipt of the temporary token, in someimplementations, the payment gateway 506 transmits the unique tokenassociated with the payment instrument (576) to the entity server 504.In this manner, for example, the entity server 504 may correlatetransaction information to a uniquely identified payment instrument.

As shown in FIG. 6, an implementation of an exemplary cloud computingenvironment 600 for enabling electronic transactions via a mobile deviceis shown and described. The cloud computing environment 600 may includeone or more resource providers 602 a, 602 b, 602 c (collectively, 602).Each resource provider 602 may include computing resources. In someimplementations, computing resources may include any hardware and/orsoftware used to process data. For example, computing resources mayinclude hardware and/or software capable of executing algorithms,computer programs, and/or computer applications. In someimplementations, exemplary computing resources may include applicationservers and/or databases with storage and retrieval capabilities. Eachresource provider 602 may be connected to any other resource provider602 in the cloud computing environment 600. In some implementations, theresource providers 602 may be connected over a computer network 608.Each resource provider 602 may be connected to one or more computingdevice 604 a, 604 b, 604 c (collectively, 604), over the computernetwork 608.

The cloud computing environment 600 may include a resource manager 606.The resource manager 606 may be connected to the resource providers 602and the computing devices 604 over the computer network 608. In someimplementations, the resource manager 606 may facilitate the provisionof computing resources by one or more resource providers 602 to one ormore computing devices 604. The resource manager 606 may receive arequest for a computing resource from a particular computing device 604.The resource manager 606 may identify one or more resource providers 602capable of providing the computing resource requested by the computingdevice 604. The resource manager 606 may select a resource provider 602to provide the computing resource. The resource manager 606 mayfacilitate a connection between the resource provider 602 and aparticular computing device 604. In some implementations, the resourcemanager 606 may establish a connection between a particular resourceprovider 602 and a particular computing device 604. In someimplementations, the resource manager 606 may redirect a particularcomputing device 604 to a particular resource provider 602 with therequested computing resource.

FIG. 7 shows an example of a computing device 700 and a mobile computingdevice 750 that can be used to implement the techniques described inthis disclosure. The computing device 700 is intended to representvarious forms of digital computers, such as laptops, desktops,workstations, personal digital assistants, servers, blade servers,mainframes, and other appropriate computers. The mobile computing device750 is intended to represent various forms of mobile devices, such aspersonal digital assistants, cellular telephones, smart-phones, andother similar computing devices. The components shown here, theirconnections and relationships, and their functions, are meant to beexamples only, and are not meant to be limiting.

The computing device 700 includes a processor 702, a memory 704, astorage device 706, a high-speed interface 708 connecting to the memory704 and multiple high-speed expansion ports 710, and a low-speedinterface 712 connecting to a low-speed expansion port 714 and thestorage device 706. Each of the processor 702, the memory 704, thestorage device 706, the high-speed interface 708, the high-speedexpansion ports 710, and the low-speed interface 712, are interconnectedusing various busses, and may be mounted on a common motherboard or inother manners as appropriate. The processor 702 can process instructionsfor execution within the computing device 700, including instructionsstored in the memory 704 or on the storage device 706 to displaygraphical information for a GUI on an external input/output device, suchas a display 716 coupled to the high-speed interface 708. In otherimplementations, multiple processors and/or multiple buses may be used,as appropriate, along with multiple memories and types of memory. Also,multiple computing devices may be connected, with each device providingportions of the necessary operations (e.g., as a server bank, a group ofblade servers, or a multi-processor system).

The memory 704 stores information within the computing device 700. Insome implementations, the memory 704 is a volatile memory unit or units.In some implementations, the memory 704 is a non-volatile memory unit orunits. The memory 704 may also be another form of computer-readablemedium, such as a magnetic or optical disk.

The storage device 706 is capable of providing mass storage for thecomputing device 700. In some implementations, the storage device 706may be or contain a computer-readable medium, such as a floppy diskdevice, a hard disk device, an optical disk device, or a tape device, aflash memory or other similar solid state memory device, or an array ofdevices, including devices in a storage area network or otherconfigurations. Instructions can be stored in an information carrier.The instructions, when executed by one or more processing devices (forexample, processor 702), perform one or more methods, such as thosedescribed above. The instructions can also be stored by one or morestorage devices such as computer- or machine-readable mediums (forexample, the memory 704, the storage device 706, or memory on theprocessor 702).

The high-speed interface 708 manages bandwidth-intensive operations forthe computing device 700, while the low-speed interface 712 manageslower bandwidth-intensive operations. Such allocation of functions is anexample only. In some implementations, the high-speed interface 708 iscoupled to the memory 704, the display 716 (e.g., through a graphicsprocessor or accelerator), and to the high-speed expansion ports 710,which may accept various expansion cards (not shown). In theimplementation, the low-speed interface 712 is coupled to the storagedevice 706 and the low-speed expansion port 714. The low-speed expansionport 714, which may include various communication ports (e.g., USB,Bluetooth®, Ethernet, wireless Ethernet) may be coupled to one or moreinput/output devices, such as a keyboard, a pointing device, a scanner,or a networking device such as a switch or router, e.g., through anetwork adapter.

The computing device 700 may be implemented in a number of differentforms, as shown in the figure. For example, it may be implemented as astandard server 720, or multiple times in a group of such servers. Inaddition, it may be implemented in a personal computer such as a laptopcomputer 722. It may also be implemented as part of a rack server system724. Alternatively, components from the computing device 700 may becombined with other components in a mobile device (not shown), such as amobile computing device 750. Each of such devices may contain one ormore of the computing device 700 and the mobile computing device 750,and an entire system may be made up of multiple computing devicescommunicating with each other.

The mobile computing device 750 includes a processor 752, a memory 764,an input/output device such as a display 754, a communication interface766, and a transceiver 768, among other components. The mobile computingdevice 750 may also be provided with a storage device, such as amicro-drive or other device, to provide additional storage. Each of theprocessor 752, the memory 764, the display 754, the communicationinterface 766, and the transceiver 768, are interconnected using variousbuses, and several of the components may be mounted on a commonmotherboard or in other manners as appropriate.

The processor 752 can execute instructions within the mobile computingdevice 750, including instructions stored in the memory 764. Theprocessor 752 may be implemented as a chipset of chips that includeseparate and multiple analog and digital processors. The processor 752may provide, for example, for coordination of the other components ofthe mobile computing device 750, such as control of user interfaces,applications run by the mobile computing device 750, and wirelesscommunication by the mobile computing device 750.

The processor 752 may communicate with a user through a controlinterface 758 and a display interface 756 coupled to the display 754.The display 754 may be, for example, a TFT (Thin-Film-Transistor LiquidCrystal Display) display or an OLED (Organic Light Emitting Diode)display, or other appropriate display technology. The display interface756 may comprise appropriate circuitry for driving the display 754 topresent graphical and other information to a user. The control interface758 may receive commands from a user and convert them for submission tothe processor 752. In addition, an external interface 762 may providecommunication with the processor 752, so as to enable near areacommunication of the mobile computing device 750 with other devices. Theexternal interface 762 may provide, for example, for wired communicationin some implementations, or for wireless communication in otherimplementations, and multiple interfaces may also be used.

The memory 764 stores information within the mobile computing device750. The memory 764 can be implemented as one or more of acomputer-readable medium or media, a volatile memory unit or units, or anon-volatile memory unit or units. An expansion memory 774 may also beprovided and connected to the mobile computing device 750 through anexpansion interface 772, which may include, for example, a SIMM (SingleIn Line Memory Module) card interface. The expansion memory 774 mayprovide extra storage space for the mobile computing device 750, or mayalso store applications or other information for the mobile computingdevice 750. Specifically, the expansion memory 774 may includeinstructions to carry out or supplement the processes described above,and may include secure information also. Thus, for example, theexpansion memory 774 may be provide as a security module for the mobilecomputing device 750, and may be programmed with instructions thatpermit secure use of the mobile computing device 750. In addition,secure applications may be provided via the SIMM cards, along withadditional information, such as placing identifying information on theSIMM card in a non-hackable manner.

The memory may include, for example, flash memory and/or NVRAM memory(non-volatile random access memory), as discussed below. In someimplementations, instructions are stored in an information carrier. thatthe instructions, when executed by one or more processing devices (forexample, processor 752), perform one or more methods, such as thosedescribed above. The instructions can also be stored by one or morestorage devices, such as one or more computer- or machine-readablemediums (for example, the memory 764, the expansion memory 774, ormemory on the processor 752). In some implementations, the instructionscan be received in a propagated signal, for example, over thetransceiver 768 or the external interface 762.

The mobile computing device 750 may communicate wirelessly through thecommunication interface 766, which may include digital signal processingcircuitry where necessary. The communication interface 766 may providefor communications under various modes or protocols, such as GSM voicecalls (Global System for Mobile communications), SMS (Short MessageService), EMS (Enhanced Messaging Service), or MMS messaging (MultimediaMessaging Service), CDMA (code division multiple access), TDMA (timedivision multiple access), PDC (Personal Digital Cellular), WCDMA(Wideband Code Division Multiple Access), CDMA2000, or GPRS (GeneralPacket Radio Service), among others. Such communication may occur, forexample, through the transceiver 768 using a radio-frequency. Inaddition, short-range communication may occur, such as using aBluetooth®, Wi-Fi™, or other such transceiver (not shown). In addition,a GPS (Global Positioning System) receiver module 770 may provideadditional navigation- and location-related wireless data to the mobilecomputing device 750, which may be used as appropriate by applicationsrunning on the mobile computing device 750.

The mobile computing device 750 may also communicate audibly using anaudio codec 760, which may receive spoken information from a user andconvert it to usable digital information. The audio codec 760 maylikewise generate audible sound for a user, such as through a speaker,e.g., in a handset of the mobile computing device 750. Such sound mayinclude sound from voice telephone calls, may include recorded sound(e.g., voice messages, music files, etc.) and may also include soundgenerated by applications operating on the mobile computing device 750.

The mobile computing device 750 may be implemented in a number ofdifferent forms, as shown in the figure. For example, it may beimplemented as a cellular telephone 780. It may also be implemented aspart of a smart-phone 782, personal digital assistant, or other similarmobile device.

Various implementations of the systems and techniques described here canbe realized in digital electronic circuitry, integrated circuitry,specially designed ASICs (application specific integrated circuits),computer hardware, firmware, software, and/or combinations thereof.These various implementations can include implementation in one or morecomputer programs that are executable and/or interpretable on aprogrammable system including at least one programmable processor, whichmay be special or general purpose, coupled to receive data andinstructions from, and to transmit data and instructions to, a storagesystem, at least one input device, and at least one output device.

These computer programs (also known as programs, software, softwareapplications or code) include machine instructions for a programmableprocessor, and can be implemented in a high-level procedural and/orobject-oriented programming language, and/or in assembly/machinelanguage. As used herein, the terms machine-readable medium andcomputer-readable medium refer to any computer program product,apparatus and/or device (e.g., magnetic discs, optical disks, memory,Programmable Logic Devices (PLDs)) used to provide machine instructionsand/or data to a programmable processor, including a machine-readablemedium that receives machine instructions as a machine-readable signal.The term machine-readable signal refers to any signal used to providemachine instructions and/or data to a programmable processor.

To provide for interaction with a user, the systems and techniquesdescribed here can be implemented on a computer having a display device(e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor)for displaying information to the user and a keyboard and a pointingdevice (e.g., a mouse or a trackball) by which the user can provideinput to the computer. Other kinds of devices can be used to provide forinteraction with a user as well; for example, feedback provided to theuser can be any form of sensory feedback (e.g., visual feedback,auditory feedback, or tactile feedback); and input from the user can bereceived in any form, including acoustic, speech, or tactile input.

The systems and techniques described here can be implemented in acomputing system that includes a back end component (e.g., as a dataserver), or that includes a middleware component (e.g., an applicationserver), or that includes a front end component (e.g., a client computerhaving a graphical user interface or a Web browser through which a usercan interact with an implementation of the systems and techniquesdescribed here), or any combination of such back end, middleware, orfront end components. The components of the system can be interconnectedby any form or medium of digital data communication (e.g., acommunication network). Examples of communication networks include alocal area network (LAN), a wide area network (WAN), and the Internet.

The computing system can include clients and servers. A client andserver are generally remote from each other and typically interactthrough a communication network. The relationship of client and serverarises by virtue of computer programs running on the respectivecomputers and having a client-server relationship to each other.

In view of the structure, functions and apparatus of the systems andmethods described here, in some implementations, an environment, systemsand methods for enabling electronic transactions are provided. Havingdescribed certain implementations of methods and apparatus forsupporting electronic transactions via a mobile device, it will nowbecome apparent to one of skill in the art that other implementationsincorporating the concepts of the disclosure may be used. Therefore, thedisclosure should not be limited to certain implementations, but rathershould be limited only by the spirit and scope of the following claims.

What is claimed:
 1. A computer system comprising: a non-transitorymemory storing instructions; and a processor configured to executeinstructions to cause the system to: receiving, at the computer system,a request from an application executing on a first computing deviceassociated with a user using a software library of the applicationprovided by a service provider associated with the computer system;determining, by the computer system based on the request, a token thatcorresponds to a payment funding source registered to the user, whereinthe token does not include an underlying identifying primary accountnumber corresponding to a payment funding source for that token;transmitting, by the computer system, the token to the first computingdevice; receiving, by the computer system, data indicating a selectionof the token for processing a transaction from the application on thefirst computing device using the software library; generating, by thecomputer system, a temporary token corresponding to the token;transmitting, by the computer system, the temporary token to the firstcomputing device; receiving, by the computer system, the transaction andthe temporary token from a second computing device of a different entityusing the software library installed on the second computing device,wherein the different entity is not provided access to the underlyingidentifying primary account number corresponding to the payment fundingsource for the token; and processing the transaction using the temporarytoken.
 2. The computer system of claim 1, wherein the software libraryincludes function calls for communicating information with anintermediary party.
 3. The computer system of claim 2, wherein theintermediary party saves at least a portion of information related tothe funding source.
 4. The computer system of claim 2, wherein theinstructions further comprising: transmitting, the at least a portion ofthe information related to the funding source, to a third computingdevice of another entity different from the different entity of thesecond computing device.
 5. The computer system of claim 2, wherein theinstructions further comprising: in response to communicating with theintermediary party, the intermediary party transmitting a unique tokenassociated with the funding source.
 6. The computer system of claim 2,wherein the intermediary party transmits codes associated with one ormore funding sources to the second computing device of the differententity.
 7. The computer system of claim 2, wherein the intermediaryparty saves at least a portion of the information related to the fundingsource in response to a accepted control selected on a user interface ofthe first computing device.
 8. A method, comprising: receiving, at acomputer system, a request from an application executing on a firstcomputing device associated with a user using a software library of theapplication provided by a service provider associated with the computersystem; determining, by the computer system based on the request, aplurality of tokens that each correspond to a particular payment fundingsource registered to the user, wherein each of the plurality of tokensdo not include an underlying identifying primary account numbercorresponding to a respective payment funding source for that token;transmitting, by the computer system, the plurality of tokens to thefirst computing device; receiving, by the computer system, dataindicating a selection of a particular token of the plurality of tokensfor processing a transaction from the application on the first computingdevice using the software library; generating, by the computer system, atemporary token corresponding to the particular token; transmitting, bythe computer system, the temporary token to the first computing device;receiving, by the computer system, the transaction and the temporarytoken from a second computing device of a different entity using thesoftware library installed on the second computing device, wherein thedifferent entity is not provided access to the underlying identifyingprimary account number corresponding to the particular payment fundingsource for the particular token; and processing the transaction usingthe temporary token.
 9. The method of claim 8, wherein the softwarelibrary includes function calls for communicating information with anintermediary party.
 10. The method of claim 9, wherein the intermediaryparty stores at least a portion of the information associated therespective payment funding source for temporary token.
 11. The method ofclaim 9, wherein the intermediary party saves at least a portion of theinformation related to the funding source in response to an acceptedcontrol selected on a user interface of the first computing device. 12.The method of claim 9, wherein the intermediary party looks up theinformation related to the funding source for transmitting to the secondcomputing device.
 13. The method of claim 9, transmitting, the at leasta portion of the information related to the funding source, to a thirdcomputing device of another entity different from the different entityof the second computing device.
 14. The method of claim 13, wherein thethird computing device of the another entity processes a transactionusing the funding associated with the temporary token.
 15. Anon-transitory machine-readable medium having stored thereonmachine-readable instructions executable to cause a machine to performoperations comprising: receiving, at a computer system, a request froman application executing on a first computing device associated with auser using a software library of the application provided by a serviceprovider associated with the computer system; determining, by thecomputer system based on the request, a token that corresponds to apayment funding source registered to the user, wherein the token doesnot include an underlying identifying primary account numbercorresponding to a payment funding source for that token; transmitting,by the computer system, the token to the first computing device;receiving, by the computer system, data indicating a selection of thetoken for processing a transaction from the application on the firstcomputing device using the software library; generating, by the computersystem, a temporary token corresponding to the token; transmitting, bythe computer system, the temporary token to the first computing device;receiving, by the computer system, the transaction and the temporarytoken from a second computing device of a different entity using thesoftware library installed on the second computing device, wherein thedifferent entity is not provided access to the underlying identifyingprimary account number corresponding to the payment funding source forthe token; and processing the transaction using the temporary token. 16.The non-transitory machine-readable medium of claim 15, wherein thesoftware library includes function calls for communicating informationwith an intermediary party.
 17. The non-transitory machine-readablemedium of claim 16, wherein the intermediary party saves at least aportion of information related to the funding source.
 18. Thenon-transitory machine-readable medium of claim 16, wherein theinstructions further comprising: in response to communicating with theintermediary party, the intermediary party transmitting a unique tokenassociated with the funding source.
 19. The non-transitorymachine-readable medium of claim 16, wherein the intermediary partytransmits codes associated with one or more funding sources to thesecond computing device of the different entity.
 20. The non-transitorymachine-readable medium of claim 16, wherein the intermediary partysaves at least a portion of the information related to the fundingsource in response to an accepted control selected on a user interfaceof the first computing device.